1. Field of the Invention
In the field of communications, SONET and SDH are a set of related standards for synchronous data transmission over fiber optic networks. SONET is short for Synchronous Optical NETwork and SDH is an acronym for Synchronous Digital Hierarchy. SONET is the United States version of the standard published by the American National Standards Institute (ANSI). SDH is the international version of the standard published by the International Telecommunications Union (ITU). This invention relates to SONET/SDH Bit Error Rate Monitoring. More specifically, the present invention relates to reducing the cost of implementation of monitoring multiple channels in parallel.
2. Description of the Prior Art
For many communication systems, the bit error rate (BER) is used as a figure of merit. In SONET/SDH systems, a receiver must be able to determine the incoming BER and react in the event that the BER is above a defined threshold. Though the number of bit errors can never be known exactly, they can be inferred by examining the number of incoming Bit-Interleaved-Parity (BIP) errors seen on an incoming channel.
FIG. 1 shows a schematic of a generally known BER test concept. From SONET/SDH specifications, we can assume that bit errors assume a Poisson distribution, which has a mean equal to its variance and can be represented by the equation:μ=σ2=λ
It follows that the probability of getting k “hits” over a given period (given that the mean number of hits over such a period is λ) is represented by the equation:
      P    k    =                    λ        k                    k        !              ⁢          e              -        λ            
Not all bit errors will be observed as a BIP error because the BIP checking mechanism is blind to any even number of errors in the same bit position. Therefore, for a given BER rate and time interval, the probability of a BIP error can be estimated as the sum of the Poisson probabilities of observing odd numbers of errors as represented by the equation:
      P    BIP    =            ∑              y        =        1            ∞        ⁢                            λ          y                          y          !                    ⁢              e                  -          λ                    ⁢                          ⁢      where      ⁢                          ⁢      y      ⁢                          ⁢      is      ⁢                          ⁢              odd        .            
We have thus reduced the occurrence of a BIP error at any one BIP position to a Bernoulli trial with probability of “success” PBIP. The variance of such a distribution will be PBIP(1−PBIP). (i.e., the variance of a Bernoulli trial) We can then determine the expected number of BIP-8 errors per frame, or the number of BIP-2 errors per multiframe by the following equation:μBIP-8=8×PBIP,μBIP-2=2×PBIP 
While the variance will be:σBIP-82=8×PBIP×(1−PBIP),σBIP-22=2×PBIP×(1−PBIP)
So for a given BER, we know the expected number of errors per frame/multiframe (λ) so we can compute the expected number of BIP errors per frame/multiframe (μBIP), and the variance of the BIP errors (σBIP2). It is by using these parameters that all prior art BER monitors are constructed. By accumulating BIP counts over specific intervals, it is possible to make a determination about the BER.
In order to be SONET/SDH compliant, there are three general criteria that must be followed.
First, the detection/removal of an alarm must be done within a specified maximum declaration/clearing time. This value depends on the level of concatenation, as well as the target and actual BER.
Second, the probability of correct detection/removal (within the maximum detection/clearing time) must be greater or equal to 99%. It should be noted that for ITU, 99% is listed as a requirement; while for Bellcore specifications, 99% is only an objective and 95% is the requirement. In this second criteria,                a. For declaration: if the target BER is 10−x and the actual BER is 10−x, then the chance that an alarm is declared within the maximum declaration time should be greater than 99%.        b. For clearing: if the target BER is 10−x and the actual BER is 10−(x+1), then the chance that the alarm is removed within the maximum clearing time should be greater than 99%.        
Third, the probability of false declaration/removal (within the maximum detection/clearing time) must be less than or equal to 10−6.                a. For declaration: if the target BER is 10−x, but the actual BER is 10−(x+1), then the chance that the monitor will detect a threshold crossing should be less than 10−6.        b. For clearing: if the target BER is 10−x and the actual BER is 10−x, conversely then the chance that an alarm will be removed should be less than 10−6.        
The above three criteria must be combined into a single test. There have been several prior art ways of constructing such a test. Some SONET/SDH specifications suggest a sliding window algorithm whereby the error counts over the last N intervals would be accumulated. As the error count for the newest interval arrives, the oldest error count is discarded. If the sum of BIP errors over an entire window exceeds a predetermined threshold, then an alarm can be declared. A sliding window example is shown in FIG. 2 with N=8 detailing the error counts for each interval, and the total for the last 8 intervals. If the total were to exceed a predetermined threshold, then an alarm could be declared.
While there are situations where a sliding window algorithm is applicable such as to test the BER of a SONET Section or Line (B1 or B2), a sliding window may be not be acceptable where tests need to be done in parallel. Still, while sliding window tests are reliable and have the shortest declaration/clearing time possible, such tests present a problem in the amount of memory needed. For each monitoring path, an entire queue (of N elements) of error counts is needed. Depending on the interval number N and the number of paths to be monitored, it can become very cumbersome to implement this in hardware.
With the drawbacks of sliding window tests in mind, designers have implemented a “jumping window” algorithm as shown by the block diagram of FIG. 3. Using this approach, there is no queue of error counts. Instead, error counts are accumulated over one window (Error Accumulation Period). After one window is complete, the error count is reset, and another accumulation of errors can begin anew. If the error count exceeds a threshold, an alarm can be declared. (Or conversely for clearing: if, at the end of an accumulation period, the number of accumulated errors is less than a pre-determined threshold, an alarm can be removed). FIG. 4 shows a jumping window timing diagram.
While the jumping window approach offer some benefits over the sliding window approach, the jumping window approach suffers from the fact that the time to declare or clear an alarm may be longer than for the sliding window (max declaration time becomes 2*[window length] rather than just the window length for the sliding window). However, it is possible to meet the maximum declaration/clearing time specifications using a jumping window approach, by ensuring the accumulation window size is less than or equal to half the maximum declaration time.
Although the jumping window algorithm can be used successfully, its implementation cost does not scale well for monitoring multiple paths. For most systems, different kinds of paths can be provisioned, e.g., STS-1, STS-3c, STS-12c, etc. The tests for each of the different path types would have different window lengths. Also, the user can set different alarm threshold for each monitoring path. For example, an STS-48 may be configured to carry 1 STS-12c, 8 STS-3c and 12 STS-1. Each kind of path could have a different target BER threshold, which implies that each monitoring path could have a different window length.
FIG. 5 shows a jumping window approach with multiple paths. Each path can have a different window length, so there will be no necessary relationship between the start and stop times of error accumulation windows for different paths. As such, the monitor for each path must be able to keep track of time on its own. To use the STS-48 example above, it would require 48 frame counters (one for each possible STS-1 path). This situation is illustrated in the block diagram of FIG. 6, where each path has its own programmable timer (frame counter). If the BER needs to be tested down to very low levels, the size of this frame counter can become extremely large.
It should be understood that SONET/SDH specifications indicate the BER testing need only be done down to the 10−9 level. However, designers often want to be able to test down to 10−12 levels in order to test that the intrinsic BER of their system is not too high. As a general rule of thumb, for testing a BER that is 10× lower, the window size will have to be 10× larger. As the window size gets larger, the programmable timers must also increase in capacity in order to accommodate them. The problem is exacerbated if VT/TU levels must be monitored for BER threshold crossings. Due to the sheer number of paths that need to be monitored, what is feasible in hardware for STS-n paths becomes too expensive for VT/TU paths. For example, if all 5376 possible VT1.5 (TU11) channels in an STS-192 (STM-64) are to be monitored, a device needs 5376 frame counters. As industry moves toward higher-density devices, the cost of the jumping window approach becomes problematic. Further, as network processors are often fully occupied with other functions, performing BER monitoring in software may also be problematic for VT/TU levels. Accordingly, it should become apparent that the jumping window is either unsuitable for VT/TU level path monitoring, or that it must be modified for it to be viable in next-generation devices and systems.
What is needed therefore is BER monitoring for SONET/SDH that is capable of monitoring multiple channels in parallel in a cost-effective and efficient manner.